-
Notifications
You must be signed in to change notification settings - Fork 4k
ARROW-14442: [R] fix behaviour when converting timestamps with "" as tzone #12240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
|
I think this is almost ready to go. 2 questions remain in my mind:
|
da5f7f6 to
89834d6
Compare
jonkeane
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the digging on this. I have a few comments about adding a few more tests.
I also wonder if we should actually be making this change at
Lines 73 to 77 in 01855c7
| auto tzone_sexp = Rf_getAttrib(x, symbols::tzone); | |
| if (Rf_isNull(tzone_sexp)) { | |
| return timestamp(TimeUnit::MICRO); | |
| } else { | |
| return timestamp(TimeUnit::MICRO, CHAR(STRING_ELT(tzone_sexp, 0))); |
which already handles some of the timezone conversion, instead of inside of Array$create(). Doing it in type_infer would mean anything that uses that code would benefit and not just be limited to Array creation
|
Any thoughts about what I suggested in #12240 (review) ? |
|
I think it would make a lot of sense to make the change at a lower level. In fact, that was a question I had on my list but never asked. I will look into the |
|
It seems some unit tests are failing on Windows due to the timezone database not being found. |
|
I'm not totally surprised that windows + timezones has popped up here. Can you tell the nature of the problem? arrow/r/tests/testthat/test-dplyr-funcs-datetime.R Lines 38 to 42 in 56e270f
might be relevant here |
341640c to
aa9f33e
Compare
|
@jonkeane could the solution be to simply skip the failing tests on Windows? |
We've done that for others like this. I would recommend going through the errors and confirming that they stem from https://issues.apache.org/jira/browse/ARROW-13168 and mark that as the reason for skipping on windows. Some of the error output in CI looks like it is, but others looked slightly different (they might have the same root cause still, but when I looked through the logs I was not 100% confident they were all ARROW-13168) |
8708968 to
c558d89
Compare
|
Currently blocked by ARROW-13168. |
|
@jonkeane I revived this PR. It looks like (most of) the Windows |
|
Yup, here's the magic: #12536 |
|
Yep, I know. I was waiting for that PR to get merged. 😉 |
jonkeane
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Woo, I like simple changes like this that just work in the end 😄
A few questions | comments
jonkeane
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great, a few suggestions + one request for one more test (or point to where it exists elsewhere...)
|
Looks good to me 👍 |
|
Benchmark runs are scheduled for baseline = e453ffe and contender = 633687c. 633687c is a master commit associated with this PR. Results will be available as each benchmark for each run completes. |
No description provided.